globus.gif (23976 bytes)

Ретрансляция кадров и речевой трафик.

Метод ретрансляции кадров разрабатывался как синхронный метод доставки данных в ISDN (и не только в ISDN). Соответственно, все реализующие этот метод механизмы и качество обслуживания определялись для всех видов трафика, кроме речевого. Традиционные сети с пакетной коммутацией, использующие различные способы коммутации пакетов, обычно применяют низкоскоростные каналы связи и не имеют возможности доставки сообщений, чувствительных к задержке. Другими словами, для этих сетей характерна большая часто меняющаяся задержка доставки сообщений.

Известно, что такая задержка обуславливается, с одной стороны, скоростью коммутации в узле связи (УС), а с другой, пропускной способностью магистральной линии связи. Значительное снижение задержки может быть достигнуто за счет применения метода ретрансляции кадров и магистральных линий связи с высокой пропускной способностью. Таким образом, FR-сеть способна “транспортировать” чувствительный к задержкам трафик. Но одно дело передача трафика данного типа по сети с динамической маршрутизацией, а другое обеспечение приемлемого качества обслуживания пользователей.

Среди проблем, связанных с передачей речевого трафика,необходимость обеспечения постоянной скорости такой передачи. Вся информация, которая содержится в оцифрованном по методу импульсно-кодовой модуляции (ИКМ) речевом сигнале, передаваемом со скоростью 64 кбит/с, важна для восстановления исходного речевого сообщения на приемной стороне. Однако разработаны методы, которые дают возможность снизить требования к полосе пропускания оцифрованного речевого сигнала:

компрессия (сжатие). Благодаря ей можно снизить скорость с 64 до 8 кбит/с и менее. Во многих известных мультиплексорах реализованы алгоритмы, позволяющие уменьшить скорость передачи. Нижний предел сжатия речевого сигнала еще не достигнут, исследования в данной области продолжаются. Конечно, при увеличении степени компрессии это начинает сказываться на качестве восстанавливаемого речевого сообщения. Однако человеческое ухо способно уловить и распознать речь, которая была подвергнута очень сильному сжатию;

детектирование шума (подавление речевых пауз). Исследования показывают, что типичная человеческая речь на 60—70% состоит из пауз. Их необходимо детектировать, чтобы исключить передачу шума через сеть и тем самым обеспечить высокую эффективность ее функционирования.

Эти и другие методы могут с успехом использоваться при пакетировании оцифрованных речевых сообщений. В настоящее время проводятся активные работы по их стандартизации и внедрению в различные службы передачи речевого трафика в пакетной форме. Большинство проблем стандартизации связано с “природой” самих сетей с пакетной коммутацией. В первую очередь, это относится к нумерации пакетов, которая необходима для обеспечения гарантированной доставки пакетов в их естественной последовательности. Дело в том, что пакеты могут иметь различные внутрисетевые задержки, обусловленные всевозможными экстремальными ситуациями в сети отказами линий и узлов связи, перегрузками, блокировками и т. п.

ITU-T принял Рекомендацию G.764, которая определяет механизм сегментирования оцифрованного речевого сигнала и формирования соответствующих пакетов. Однако этот стандарт не решает многих проблем, к которым относятся:

детектирование шума с целью снижения объема входного трафика. Необходимо детализировать процедуры анализа входного речевого трафика, подавления речевых пауз и передачи синхронизирующих последовательностей для определения начала и окончания речевых и “неречевых” последовательностей;

нумерация серий пакетов для обеспечения доставки последних в их естественной последовательности. В случае потери пакета возможно одно из двух решений: а) повторная передача пакета от источника (что резко повышает общесетевую задержку); б) передача адресату “паузы” в том месте последовательности, где должен был находиться утерянный пакет;

задержка при обеспечении синхронизации, цель которойисключение нарушений в обслуживании пользователей.

Процедура состоит из синхронизации всех пакетов, при передаче которых каждый УС вносит свою индивидуальную транзитную задержку. На приемной стороне входящие пакеты накапливаются в приемном буфере и поступают в ООД с постоянной задержкой. С Рекомендацией G.764 тесно связана Рекомендация G.727, которая определяет процедуры обработки речевого сигнала в соответствии с алгоритмом адаптивной дифференциальной ИКМ (АДИКМ) и вводит понятия “информационных” и “дополнительных служебных” бит. Рекомендация G.727 устанавливает механизм разделения “речевого” пакета на составные части, в одной из которых размещаются информационные биты, а в другой дополнительные служебные биты. Целью такого разделения является обеспечение возможности уничтожения (при необходимости) дополнительных служебных бит при доставке “речевых” пакетов, что приводит к уменьшению длины последних. А это, в свою очередь, способствует снижению сетевой нагрузки.

Базовая FR-сеть должна обеспечивать следующее:

FRF принял только один стандарт для FR-сетей, специализирующихся на передаче речевого трафика. В нем была предпринята попытка “перенесения” Рекомендации ITU-T G.764, определяющей стандарты для пакетирования речевого трафика, в стандарты FR. Пакет G.764 имеет две части, в первой из которых размещены информационные биты, а во второйслужебные. Следовательно, этот пакет может быть “вложен” в два кадра FR, один из которых включает в себя заголовок кадра и информационные биты, а другой заголовок кадра и служебные биты.

17_1.jpg (44216 bytes)

рисунок 17. Преобразование пакета G.764 в FR-кадры.

АКД всегда будет устанавливать такое значение CIR, при котором кадры с информационными битами будут гарантированно доставляться через сеть. В кадрах с дополнительными битами DE (бит, указывающий на то, что при необходимости данный кадр можно уничтожить) будет всегда устанавливаться в “1” абонентским оборудованием (в точке доступа к сети). Следовательно, такие кадры будут восприниматься АКД как не требующие выделения дополнительного ресурса пропускной способности.

При таком подходе возможна передача речевого трафика через FR-сеть, но все процедурные детали механизма доставки должны быть заранее оговорены.


back.gif (9484 bytes)    top.gif (8854 bytes)    next.gif (9311 bytes)

Hosted by uCoz